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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 60 
countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 



Introduction 



The frequency bands used for broadcasting below 30 MHz are: 

• Low Frequency (LF) band - from 148,5 kHz to 283,5 kHz, in ITU Region 1 [i.l] only; 

• Medium Frequency (MF) band - from 526,5 kHz to 1 606,5 kHz, in ITU Regions 1 [i.l] and 3 [i.l] and from 
525 kHz to 1 705 kHz in ITU Region 2 [i.l]; 

• High Frequency (HE) bands - a set of individual broadcasting bands in the frequency range 2,3 MHz to 
27 MHz, generally available on a Worldwide basis. 

These bands offer unique propagation capabilities that permit the achievement of: 



• 



large coverage areas, whose size and location may be dependent upon the time of day, season of the year or 
period in the (approximately) 1 1 year sunspot cycle; 

• portable and mobile reception with relatively little impairment caused by the environment surrounding the 
receiver. 

There is thus a desire to continue broadcasting in these bands, perhaps especially in the case of international 
broadcasting where the HF bands offer the only reception possibilities which do not also involve the use of local 
repeater stations. 
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However, broadcasting services in these bands: 

• use analogue techniques; 

• are subject to limited quaUty; 

• are subject to considerable interference as a result of the long-distance propagation mechanisms which prevail 
in this part of the frequency spectrum and the large number of users. 

As a direct result of the above considerations, there is a desire to effect a transfer to digital transmission and reception 
techniques in order to provide the increase in quality which is needed to retain listeners who, increasingly, have a wide 
variety of other programme reception media possibilities, usually already offering higher quality and reliability. 

In order to meet the need for a digital transmission system suitable for use in all of the bands below 30 MHz, the Digital 
Radio Mondiale (DRM) consortium was formed in early 1998. The DRM consortium is a non-profit making body 
which seeks to develop and promote the use of the DRM system worldwide. Its members include broadcasters, network 
providers, receiver and transmitter manufacturers and research institutes. More information is available from their 
website ( http://www.drm.org/) . 

In March 2005, the DRM Consortium voted at its General Assembly to embark on extending the capability of the DRM 
system to provide digital radio services at higher transmission frequencies. This range includes: 

• 47 MHz to 68 MHz (Band I) allocated to analogue television broadcasting; 

• 65,8 MHz to 74 MHz (OIRT FM band) 

• 76 MHz to 90 MHz (Japanese FM band) 

• 87,5 MHz to 107,9 MHz (Band II) allocated to FM radio broadcasting. 
This extension completes the family of digital standards for radio broadcasting. 
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Scope 



The present document gives the specification for the link between a Digital Radio Mondiale (DRM) Multiplexer and a 
DRM Modulator. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI ES 201 980: "Digital Radio Mondiale (DRM); System Specification". 

NOTE: Clause numbers, where quoted, refer to ES 201 980 (V3. 1 . 1). 

[2] ETSI TS 102 821: "Digital Radio Mondiale (DRM); Distribution and Communications Protocol 

(DCP)". 

[3] ISO/lEC 10646: "Information technology - Universal Multiple-Octet Coded Character Set (UCS)". 

[4] ETSI TS 102 358: "Digital Radio Mondiale (DRM); Specific Restrictions for the use of the 

Distribution and Communication Protocol (DCP)". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] ITU Radio Regulations. 



3 Definitions, symbols, abbreviations and conventions 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Alternative Frequency Switching (AFS): feature of the DRM multiplex which allows receivers to automatically 
re-tune to a frequency offering more reliable reception without a break in the decoded audio 

byte: collection of 8 -bits 

Distribution and Communication Protocol (DCP): transport layer communications protocol providing fragmentation, 
addressing and/or reliable data transmission over errored channels using a Reed Solomon code to provide Forward 
Error Correction (EEC) 
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Fast Access Channel (FAC): channel of the multiplex data stream that contains the information that is necessary to 
find services and begin to decode the multiplex 

Greenwich Mean Time (GMT): historically the standard time for all international applications, now superseded by 
UTC 

Global Position System (GPS): constellation of satellites providing accurate time and position information to receivers 

GPS Time: time signal broadcast by the GPS satellites using an epoch of January 6* 1980 with no leap seconds and a 
"week number" (actually a modulo-604 800 seconds number) that wraps every 1 024 weeks (approximately 19,7 years) 

logical frame: contains data of one stream during 400 ms for robustness modes A to D or 100 ms for robustness 
mode E 

multiplex frame: logical frames from all streams form a multiplex frame 

NOTE: It is the relevant basis for coding and interleaving. 

Main Service Channel (MSC): channel of the multiplex data stream which occupies the major part of the transmission 
frame and which carries all the digital audio services, together with possible supporting and additional data services 

MDI Packet: A TAG: packet containing those TAG Items as defined in the present document 

Modified Julian Date (MJD): date format based on the number of days since midnight GMT on 17'*' 
November 1858 AD 

NOTE: Time can be represented as a fraction of a day, however as MJD is subject to leap seconds, the fractional 
part corresponding to an SI second is of variable size and hence complex to implement in a fixed width 
bit-field. 

Multi-Frequency Network (MFN): network of transmitters serving a large geographic area using different radio 
frequencies to achieve improved reliability of reception 

NOTE: The transmitters might not be synchronized in time (non-synchronized MFN, see annex A), and so the 
AFS feature of DRM may not operate correctly. 

Service Description Channel (SDC): channel within the multiplex data stream that gives information necessary to 
decode the services included in the multiplex 

NOTE: The SDC also provides additional information to enable a receiver to find alternate sources of the same 
data. 

Single Frequency Network (SFN): network of transmitters sharing the same radio frequency to cover a large area 

Synchronized Multi-Frequency Network (SMFN): network of transmitters serving a large geographic area using 
different radio frequencies to achieve improved reliability of reception 

NOTE: The transmitters are synchronized in time to allow the AFS feature of the transmitted signal to operate 
correctly. 

TAG Item: DCP elemental type combining in a single logical data the name, length and value of the data 

TAG Name: name field within an individual TAG Item used to identify an individual piece of information 

TAG Packet: collection of TAG Items with a header carrying a cohesive and self-contained block of data 

TAG Value: payload of a TAG Item 

International Atomic Time (literally Temps Atomique International) (TAI): time format counting in standard 
SI seconds 

NOTE: TAI and GPS Time have a constant offset of 19 s. 

transmission frame: number of consecutive OFDM symbols, wherein the first OFDM symbol contains the frame 
synchronization cells 
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transmission super-frame: three consecutive transmission frames (robustness modes A to D) or four consecutive 
transmission frames (robustness mode E), wherein the first OFDM symbols contain the SDC block 

Coordinated Universal Time (literally Universel Temps Coordonne) (UTC): time format counting in standard 

SI seconds with periodic adjustments made by the addition (or removal) of leap seconds to keep the difference between 

UTC and Astronomical Time less than +0,9 s 



NOTE: 



TAJ and UTC were defined as having an initial offset of 10 s on January P'^ 1972 (TAI prior to this date 
had a variable fractional offset to UTC as the two times did not use the same definition of the second). As 
at 25*^ February 2003 there have been 22 leap seconds, all positive, making TAI = UTC + 32. 



3.2 Symbols 



For the purposes of the present document, the following symbols apply: 



N. 



The value "N" is expressed in radix "x". The radix of "x" shall be decimal, thus 2Ajg is the 
hexadecimal representation of the decimal number 42. 



3.3 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AF Application Framing 

AFS Alternative Frequency Switching 

BOOTP BOOT Protocol 

CRC Cyclic Redundancy Check 

DC? Distribution and Communication Protocol 

DHCP Dynamic Host Configuration Protocol 

DRM Digital Radio Mondiale 

FAC Fast Access Channel 

EEC Forward Error Correction 

GMT Greenwich Mean Time 

GPS Global Positioning System 

HE High Frequency 

IP Internet Protocol 

ISO International Organization for Standardization 

LF Low Frequency 

LSb Least Significant bit 

LSB Least Significant Byte 

MDI Multiplex Distribution Interface 

ME Medium Frequency 

MEN Multi -Frequency Network 

MJD Modified Julian Date 

MSb Most Significant bit 

MSB Most Significant Byte 

MSC Main Service Channel 

OFDM Orthogonal Frequency Division Multiplexing 

RE Radio Frequency 

rfu reserved for future use 

SDC Service Description Channel 

SEN Single Frequency Network 

SMEN Synchronized Multi-Frequency Network 

TAG Tag, Length, Value 

TAI International Atomic Time (Temps Atomique International) 

UDP User Datagram Protocol 

UTC Co-ordinated Universal Time (Universel Temps Coordonnee) 

UTCO Co-ordinated Universal Time (Universel Temps Coordonnee) Offset 
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3.4 Conventions 

The order of bits and bytes within each description shall use the following notation unless otherwise stated: 

• in figures, the bit or byte shown in the left hand position is considered to be first; 

• in tables, the bit or byte shown in the left hand position is considered to be first; 

• in byte fields, the Most Significant bit (MSb) is considered to be first and denoted by the higher number. For 
example, the MSb of a single byte is denoted "b-y" and the Least Significant bit (LSb) is denoted "bQ"; 

• in vectors (mathematical expressions), the bit with the lowest index is considered to be first. 



4 General description 

4.1 System overview 

The Multiplex Distribution Interface carries the description of a complete DRM Multiplex from the equipment 
generating the data (the DRM Multiplex Generator) to the DRM Modulator in such a way that reliable networks of 
transmitters (MFN, SMFN and SFN) can be constructed. Typically the DRM Multiplex Generator will be sited at the 
studio centre, although some systems may locate it at the transmitter or at a third-party multiplex provider. The DRM 
Modulator will almost invariably be located at the transmitter site, and in many networks, several such sites will 
combine to form a comprehensive network using one or more RF channels. 



4.2 System architecture 



The protocol stack provided by the Distribution and Communication Protocols (TS 102 821 [2]) is described in figure 1. 
As can be seen, the Multiplex Distribution Interface as described in the present document builds upon the DCP stack, 
defining the TAG Items to be used and the format of the data carried. The result is a collection of TAG Items which can 
be carried in a single TAG packet and which together contain all the data necessary for the DRM Modulator to produce 
one logical frame of output. For robustness modes A to D, one DRM logical frame contains content for 400 ms of 
broadcast signal; for robustness mode E it contains content for 100 ms of broadcast signal. When carrying TAG Items 
conforming to the present document, a TAG Packet is known as an MDI Packet. 
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Content to broadcast 



i 



DRM Multiplex Generator 



Tag, Length, Value 
(TAG) 



Application Framing 
(AF) 



Protection, Fragmentation 

and Transportation 

(PFT - optional) 



File 



Serial 



UDP/IP 



-Logical data link- 
Multiplex 
Distribution 
Interface (MDI) 



Distribution and 

Communication 

Protocols 

(DCP) 



RF signal to transmitter 



1 



DRM Modulator 



-Physical data link- 



Tag, Length, Value 
(TAG) 



Application Framing 
(AF) 



Protection, Fragmentation 

and Transportation 

(PFT - optional) 



File 



Serial 



UDP/IP 



T 



Figure 1 : MDI and DCP protocol stack 



A detailed description of: 



• the DRM broadcast chain and its transmission protocols; 

• supported hardware interfaces; and 

• mandatory parameters and general restrictions to the general purpose Distribution & Communication Protocol 
("DCP") for the use within DRM, 

is given in the document TS 102 358 [4]. 

NOTE: It is possible to receive multiple AF Packets or PFT Packets with identical content. This is not an error. 
The extra AF Packets or PFT Packets should be ignored by the receiving device. An AF Packet can be 
assumed to be identical if its AF Header (including the length and sequence number), actual packet length 
and CRC value are identical. A PFT Packet can be assumed to be identical if its PFT Header (including 
the HCRC value) and the actual packet length are identical. 
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4.2.1 TAG items and packets (informative) 

For ease of reference, the basic structure of a TAG Packet and the TAG Items it contains is described in figure 2. The 
normative definition is contained in TS 102 821 [2]. 



TAG Packet TAG Item 



TAG Item TAG Item 



TAG Item 



TAG 
padding 

-<8 bytes- 



TAG Item 



Name 



Length 



Value 



h4 bytes>i<-4 bytes >i<- 



-Length bits- 



TAG Item 
padding 



-►+^<8 bits- 



— Total length always a whole number of 8-bit bytes — 

Figure 2: TAG Packets and TAG Item overview 



TAG items 



Each MDI Packet consists of a number of TAG Items where each TAG Item carries a single piece of information. When 
combined, the TAG Items present in one MDI Packet completely describe one DRM logical frame. Upon reception of 
an MDI Packet, one DRM transmission frame may be produced. A DRM transmission super-frame may be produced 
from three consecutive MDI Packets for robustness modes A to D or four consecutive MDI Packets for robustness 
mode E (as defined by the "dlfc" TAG item, see clause 5.1.2). 

The FAC, SDC (if present) and MSC data carried within one MDI Packet belong together, and describe one DRM 
logical frame. For example: When the reconfiguration index after a reconfiguration announcement reaches for the first 
time, the MSC data of the same MDI Packet is the first MSC data to be configured according to the updated FAC/SDC 
information. 

For robustness modes A to D: 

• In the case of short interleaving, the FAC, SDC and MSC from one MDI packet shall be broadcast within the 
same 400 ms DRM transmission frame (signal on air). 

NOTE: Strictly, one frame's worth of MSC data is not confined exactly to one transmission frame even for short 
interleaving. Instead the first multiplex frame continues into the beginning of the second transmission 
frame and the second multiplex frame continues into the third transmission frame, because of the 
presence of the SDC symbols in the first frame. For the purposes of the above explanation the multiplex 
frame is equated with the transmission frame of the same index, i.e. the frame that carries most of the 
MSC cells of the multiplex frame. 

• In case of long interleaving, the DRM transmission frame (signal on air) containing a particular FAC 
information only carries the first part of the related MSC data of the same DRM logical frame. While the FAC 
(and optionally the SDC) information of the current DRM logical frame is fully transmitted within one DRM 
transmission frame of 400 ms, the corresponding MSC data is spread over the current plus the following 4 
consecutive DRM transmission frames. 

For robustness mode E: 

• The DRM transmission frame (signal on air) containing a particular FAC information only carries the first part 
of the related MSC data of the same DRM logical frame. While the FAC (and optionally the SDC) information 
of the current DRM logical frame is fully transmitted within one DRM transmission frame, the corresponding 
MSC data may be spread over the current plus the following 5 consecutive DRM transmission frames. 

Within a single MDI Packet, each TAG Name shall be unique. No TAG Name may occur multiple times within a single 
MDI Packet. 

Mandatory TAG Items must be supported by every MDI implementation, although not every Mandatory TAG Item will 
appear in every MDI Packet unless stated in the descriptions below. 
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The MDI also defines additional TAG Items which may be supported by some implementations - these are known as 
optional TAG Items and extend the basic MDI implementation. These TAG Items should be ignored without error by 
equipment not supporting the appropriate feature(s). 

Additional proprietary TAG Items may be supported by individual implementations but do not form part of the MDI 
specification and should be ignored without error by equipment not recognizing the TAG Name. No MDI conformant 
equipment shall produce or require any additional information other than as described in the present document in order 
to work according to the DRM System Specification (ES 201 980 [1]). 



5.1 Mandatory TAG items 



DRM equipment receiving/decoding MDI shall correctly decode and interpret the following TAG Items. DRM 
equipment generating MDI shall generate all the following TAG Items, unless an exception is explicitly stated for 
individual TAG Items. 

Table 1 : Mandatory TAG items 



TAG Name 
(ASCII) 


TAG Length 
(bits) 


TAG Value 


*ptr 


64 


Control TAG Item "Protocol Type and Revision"; see the DCP definition 
(TS 102 821 [2]) for format and interpretation details. 


difc 


32 


DRM logical frame counter: this value identifies a single MDI Packet. 


fac_ 


72 or 120 


FAC data for one DRM logical frame (64 data bits + 8-bit-CRC for robustness 
modes A to D or 1 1 2 data bits+ 8-bit-CRC for robustness mode E). See the 
DRM System Specification (ES 201 980 [1]) for a full description. 


sdc_ 


variable 


SDC data block for one DRM logical frame (incl. 16-bit-CRC). See the DRM 
System Specification (ES 201 980 [1]) for a full description. 


sdci 


32 (1 stream) 
56 (2 streams) 
80 (3 streams) 
104 (4 streams) 


SDC Information contains the complete "Multiplex Description Data Entity - type 
0" as described in the DRM System Specification (ES 201 980 [1]). 


robm 


8 


Current robustness mode; 

Encoding: 0x00 = robustness mode A; 

0x01 = robustness mode B; 

0x02 = robustness mode C; 

0x03 = robustness mode D; 

0x04 = robustness mode E. 


strO 


variable 


The data for MSC stream for one DRM logical frame. 


strl 


variable 


The data for MSC stream 1 for one DRM logical frame, if any. 

If stream 1 is not present in the multiplex, this TAG Item shall be omitted or 

have zero length. 


str2 


variable 


The data for MSC stream 2 for one DRM logical frame, if any. 

If stream 2 is not present in the multiplex, this TAG Item shall be omitted or 

have zero length. 

If stream 1 is not present in the multiplex, stream 2 shall also be omitted or have 

zero length. 


str3 


variable 


The data for MSC stream 3 for one DRM logical frame, if any. 

If stream 3 is not present in the multiplex, this TAG Item shall be omitted or 

have zero length. 

If stream 2 is not present in the multiplex, stream 3 shall also be omitted or have 

zero length. 



£75/ 



13 



ETSI TS 102 820 V3.1.1 (2010-12) 



5.1 .1 Protocol type and revision (*ptr) 

This TAG Item shall be included in every MDI Packet. 



TAG Name 



TAG Length 



TAG Value 



ASCII "*ptr" 


64 bits 


Protocol 


Major 


Minor 


* 


P 


t 


r 


00i6 


00,6 


00i6 


40,6 


D 


M 


D 


1 


00,6 


00,6 


00,6 


00,6 




-4 bytes - 


»4< 4 bytes ►-< 




-8 bytes- 















Figure 3: Protocol type and revision 

Protocol type: The ASCII string "DMDI" (DRM Multiplex Distribution Interface). 
Major revision: Currently 0001 jg. 

NOTE 1 : If the MDI Packet carries content for robustness modes A to D, the major revision number OOOO^g may be 
used to maintain compatibility with version 0.0 MDI implementations. Content for robustness mode E 
requires the use of MDI version 1.0. 

NOTE 2: The value of the mandatory 'robm' TAG Item may be checked to identify whether MDI Packets are 
scheduled to be transmitted every 400 ms (robustness modes A to D) or every 100 ms (robustness 
mode E). 

Minor revision: Currently 0000 ^g. 

For further information on the revision numbering, refer to clause 5.3. 



5.1 .2 DRM logical frame count (difc) 

This TAG Item shall be included in every MDI Packet. 



TAG Name 



TAG Length 



TAG Value 



ASCII "difc" 



I f 



32 bits 



00„ 



oo„ 



00„ 



20„ 



Logical framecount 



OOOOOOOO^g... FFFFFFFF^g 



-4 bytes - 



-+"<- 



-4 bytes - 



-4 bytes- 



Figure 4: DRIV! logical frame count 



Logical frame count: The value shall be incremented by one by the device generating the MDI Packets for each MDI 
Packet sent. In the event that the maximum value is reached, the counter shall reset to zero . . ., FFFFFFE^g, 

FFFFFFFF^g, OOOOOOOO^g, 00000001 ^g, .... The receiver shall not expect or require the first packet received to have a 
specific value of logical frame count. This value shall be used by the receiver of the MDI Packet to ensure that packets 
which arrive out-of-order are re-ordered correctly. The logical frame count may also be used to detect lost MDI Packets 
and, if a suitable link exists, request retransmission of the lost packet. 

NOTE: Identical MDI Packets might be received multiple times. This is not an error. Instead, the receiving device 
should just ignore the extra MDI Packets with identical content (i.e. at least the same "difc", AF Header 
content and AF-CRC value). 
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5.1 .3 Fast access channel (facj 

This TAG Item shall be included in every MDI Packet. 



TAG Name 



TAG Length 



TAG Value 



ASCII "fac 



72 or 120 bits 



48i6or78i6 



Channel 
parameters 



Service parameters 



CRC 



-4 bytes- 



T 

I 



-20 bits- 



->"<- 



-44 or 92 bits- 



-4 bytes- 



-X- 



-9 or 1 5 bytes- 



-X8 bits-H 

> 



Figure 5: Fast access channel 

Channel parameters: as described in ES 201 980 [1], clause 6.3.3. 

Service parameters: as described in ES 201 980 [1], clause 6.3.4. The data carried in the Service Parameters shall be 
repeated according to the FAC repetition rules described in ES 201 980 [1], clause 6.3.6. The length of this section 
depends on the DRM robustness mode: 44 bits (1 service description) for robustness modes A to D or 92 bits (2 service 
descriptions of 44 bits each plus 4 bits padding set to 0) for robustness mode E. 

CRC: as described in ES 201 980 [1], clause 6.3.5. 

5.1 .4 Service description cinannel (sdc_) 

This TAG Item shall only be included in the MDI Packet containing the data for the first logical frame in each 
transmission super-frame. This TAG Item shall not be included in any other MDI Packets. 



TAG Name 



TAG Length 



TAG Value 



ASCII "sdc_" 


[Qn + 24) bits 


Service Description Channel Block 


s 


d 


c 


— 


Rfu 


AFS 
Index 


SDC data 


CRC 




► 




4 bytes ► 


s 




i 


-^4 bits— ► 

< 


^ A hit'^ k 


T 


1 


^ On Ki+i^ w:.rf -1 C Kitr% Wi 


< 


-4bi 


^tes- 


(n+3) bytes ► 



Figure 6: Service description channel 

Rfu: these four bits are reserved for future use and shall have the value zero. 

AFS index: as described in ES 201 980 [1], clause 6.4.2. 

SDC data: as described in ES 201 980 [1], clause 6.4.3. 

CRC: as described in ES 201 980 [1], clause 6.4.2. 

The value of "n" depends upon the robustness mode, SDC mode and spectrum occupancy of the DRM ensemble as 
described in ES 201 980 [1], clause 6.4.2, table 61 which lists values in the range 13 to 207. 
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5.1 .5 Service description cinannel information (sdci) 

This TAG Item shall be included in every MDI Packet. 





TAG Name 




TAG Length 










TAG Value 




ASCII "sdci" 


(24n+32) bits 


Protection 


n+1 stream description(s) 


s 


d 


c 


i 


Rfu 


p 

L 
A 


P 
L 
B 


Stream 
Description 




Stream 
Description n 




-4 bytes X 4 bytes — 


4 bits 2 bits 










2 bits 







Figure 7: Service description chiannel information 

Rfu: these four bits are reserved for future use and shall have the value zero. 

PLA and PLB: the protection level as described in ES 201 980 [1], clause 7.5.1. 

Stream Description n: the stream description for an individual MSC stream - see ES 201 980 [1], clause 6.4.3.1. Up to 
four stream descriptions may be included, the corresponding stream data being carried in the MDI strO, strl, str2 and 
str3 TAG Items respectively. 



5.1 .6 Robustness mode (robm) 

This TAG Item shall be included in every MDI Packet. 



TAG Name 



TAG Length 



TAG Value 



ASCII "robm" 


8 bits 


Robustness mode 


r 





b 


m 


00,e 


00,e 


00,e 


08,e 


< 4 bytes >^< 4 bytes ► 







Figure 8: Robustness mode 



Robustness mode: the robustness mode to be used encoded as shown in table 2. All other values are reserved for future 
use. 



Table 2: Robustness mode encoding 



Value 


Robustness mode 


00i6 


A 


01l6 


B 


02i6 


C 


03i6 


D 


04i6 


E 



NOTE 1: The value 04jg is not available for the MDI protocol version 0.0. 

NOTE 2: The value of the "robm" TAG Item may be checked to identify whether MDI Packets are scheduled to be 
transmitted every 400 ms (robustness modes A to D) or every 100 ms (robustness mode E). 
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5.1 .7 Stream <n> (strO, str1 , str2 and str3) 

The strO, strl, str2 and str3 TAG Items shall contain the data for the corresponding DRM stream. If the TAG Length is 
zero, the TAG Item may be omitted from the MDI Packet. 



TAG Name 



TAG Length 



TAG Value 



ASCII StrO, stn, 
str2 or str3 


8n bits 


Data 


s 


t 


r 






-4 bytes - 



-+-<- 



-4 bytes - 



->-<- 



-n bytes- 



Figure 9: Stream data 
Data: the content of one of the streams present in the DRM multiplex. 

5.2 Optional TAG items 

Every DRM MDI implementation may choose to support the following optional TAG Items. Where one or more of the 
optional TAG Items are supported, they shall behave as described below. When not supported by an implementation, 
the presence of these TAG Items shall be ignored. 

Table 3: Optional TAG Items 



TAG Name 
(ASCII) 


TAG Length 
(bits) 


TAG Value 


info 


variable 


Free-form textual information. 


tist 


64 


This TAG Item specifies the point In time at which the DRM transmission frame 
should be broadcast. 



5.2.1 Information (info) 

This TAG Item may be included in any MDI Packet. 





TAG Name 


1 


TAG Length 


TAG Value 


ASCII "info" 


8n bits 


UTF-8 text 


i 


n 


f 






-4 bytes - 



-»-<- 



-4 bytes - 



->-<- 



-n bytes- 



Figure 10: Info TAG item 



UTF-8 Text: an arbitrary number of bytes encoding a text string using UTF-8 (ISO/IEC 10646 [3]). No fixed purpose 
is defined for this string, however it is envisaged that the value may be displayed by a DRM Modulator. This could be 
used for any purpose, for example to identify the DRM Multiplex or the DRM Multiplexer providing the MDI Packets 
being processed or to provide warnings, additional information, statistics, etc. 
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5.2.2 Timestamp (tist) 



This TAG Item shall be included in every MDI Packet intended to be broadcast using an SFN or SMFN. It may be 
included in any other MDI Packet if desired. 





TAG Name 


1 


TAG Length 




TAG Value 




ASCII "tist" 


64 bits 


UTCO 


DRIVI Timestamp 


t 


i 


s 


t 


00,6 


00,e 


00,6 


40,e 


Seconds 


Milliseconds 


< 


-4 bytes- 


*~< 4 bytes » 








'■* 


8 bytes 


H 



Figure 1 1 : Timestamp 

UTCO: the offset (in seconds) between UTC and the Seconds value. The value is expressed as an unsigned 14-bit 
quantity. As of 2000-01-01 T 00:00:00 UTC, the value shall be zero. As of 2009-01-01 T 00:00:00 UTC the value shall 
be 2. The value shall change as a result of each further leap second applied to UTC. The value contained in this field 
shall have no effect on the time of emission from the modulator. 

Seconds: the number of SI seconds since 2000-01-01 T 00:00:00 UTC as an unsigned 40-bit quantity. 

Milliseconds: the number of milliseconds ( V^qoo'^'' of ^^^ ■^^ second) since the time expressed in the Seconds field. The 
value is expressed as an unsigned 10-bit quantity. The values 1 000 to 1 023 inclusive are reserved for future use. 

DRM Timestamp: taken together, the Seconds and Milliseconds values produce the DRM Timestamp value that 
defines the time at which 50 % of the energy of the first time sample from the IFFT of the first symbol of the DRM 
transmission frame shall have been radiated on air. Each subsequent MDI packet (as defined by the "dlfc" value, see 
clause 5. 1 .2) shall have a timestamp value which increases by 400 ms for robustness modes A to D) or 100 ms for 
robustness mode E. The chosen bit-widths allow DRM Timestamp to represent uniquely any date/time from 2 000 AD 
until approximately 34 800 AD with a resolution of one millisecond. Conversion between DRM Timestamp and other 
standard time references is outlined in annex B. 

NOTE: The binary value of the combined DRM Timestamp field does not increase uniformly due to the modulo- 
1 000 milliseconds count. 

It is the function of the DRM Multiplexer to allow sufficient time when encoding this value to enable the longest 
transmission path to deliver the data before it is required by the DRM Modulator. All modulators supporting this TAG 
Item shall provide at least ten seconds of buffering of MDI Packets. 

5.3 Revision history 

Table 4 contains the history of the TAG Item changes of the MDI Protocol for each new revision. 

Table 4: Revision history 



Major 
revision 


Minor 
revision 


Date 


Changes from previous to new revision 


OOOO^g 


OOOOig 


2003-02-04 


Initial revision 


0001 ig 


OOOOig 


2010-03-01 


Values and definitions for robustness mode E added; 
version 0.0 implementations can only handle values 
defined for robustness modes A to D. 



Changes to the protocol which will allow existing decoders to still function will be represented by an increment of the 
minor version number only. Any new features added by the change will obviously not need to be supported by older 
modulators. Existing TAG Items will not be altered except for the definition of bits previously declared Rfu. New TAG 
Items may be added. 
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Changes to the protocol which will render previous implementations unable to correctly process the new format will be 
represented by an increment of the major version number. Older implementations should not attempt to decode such 
MDI packets. Changes may include modification to or removal of existing TAG Item definitions. 
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Annex A (informative): 
Typical DRIVI networks 



The following list describes some of the possible options for building SFN/SMFN/MFN networks. The intention is to 
clarify the use of the "tist" TAG which is only mandatory for SFN or SMFN networks. 

• Single Frequency Networks (SFN): 

All DRM transmitters broadcast an identical DRM signal such that they appear at the receiving antenna 
nominally at the same time and on the same frequency. Such signals received simultaneously by a DRM 
compliant receiver may increase the reception quality. The DRM timestamp TAG Item tist (together with 
any locally configured timing offset) is used to ensure that the transmitters are accurately synchronized. 
The typical timing accuracy required is around 0,5 % of the guard interval for the transmission mode in 
use, approximately +13,3 [is in robustness mode A, +26,65 |is in robustness modes B and C, +36,65 |is 
in robustness mode D, +1,25 |is in robustness mode E. 

• Synchronized Multi-Frequency Networks (SMFN): 

All DRM transmitters broadcast identical DRM signals such that they appear at the receiving antenna 
nominally at the same time but on different frequencies. This allows the receiver to exploit the 
Alternative Frequency Switching (AFS) feature of DRM to seamlessly switch to an alternative 
frequency. The DRM timestamp TAG Item tist (together with any locally configured timing offset) is 
used to ensure that the transmitters are accurately synchronized. The typical timing accuracy required is 
around 1 % of the SDC duration, approximately 533,2 |is in robustness modes A and B, +600,0 |is in 
robustness mode C, +499,8 |is in robustness mode D and +125,0 |is in robustness mode E. 

• Non-synchronized Multi-Frequency Networks (MFN): 

All DRM transmitters broadcast similar or identical DRM signals such that they appear at the receiving 
antenna at slightly different times and on different frequencies. This does not allow the use of the 
Alternative Frequency Switching (AFS) feature but still allows a non-seamless switch to an alternative 
frequency. The DRM timestamp TAG Item tist (together with any locally configured timing offset) may 
be used if desired to achieve synchronization between the transmitters. 

• Single transmitter: 

The DRM transmitter is the only one broadcasting the DRM Multiplex. AFS support is not appropriate 
as there is only one transmitter, however it is possible to non-seamlessly switch to an alternative 
frequency carrying one or more of the services in the current multiplex. 
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Annex B (informative): 
DRIVI Timestamps 

B.1 Relationships 

The relationships between UTC, TAI, GPS Time and DRM Timestamp (as defined in clause 5.2.2) are, as at the time of 
writing (March 2010), as follows: 

GPS = TAI -19 s (constant). 

UTC = TAI - 34 s (variable due to leap seconds). 

UTC = GPS -15 s (variable due to leap seconds). 

UTC = DRM - UTCO (constant due to varying value of UTCO). 

DRM = TAI - 32 s (constant). 

DRM = GPS -13 s (constant). 

DRM = UTC + UTCO (constant due to varying value of UTCO). 



B.2 Rationale 



Several other standard time/date encodings are in common use, including MJD, UTC, GPS and TAI. It was agreed that 
none of these adequately addressed the needs of a DRM system and that it was desirable to define a time format 
specifically for the DRM Timestamp. The following reasons were given for rejecting other common timebases: 

• MJD is subject to leap seconds making the fractional portion very hard to represent in a fixed-point format. 

• UTC is subject to leap seconds making the number of seconds in a day variable (86 399 / 86 400 / 86 401). 

• GPS Time is subject to "week number wrapping" approximately every 19,7 years. 

• UTC, TAI, MJD and GPS Time all have epochs (start dates) partway through the 400-year leap-year cycle. 

The DRM Timestamp is not subject to leap seconds but contains sufficient extra information (in the UTCO field) to 
trivially convert the value to UTC which does include leap-seconds. Conversion to GPS Time and/or TAI is also trivial, 
simply involving the subtraction of a constant value. The epoch for DRM Time is synchronized with the start of a 
400-year leap-year cycle, making leap-year calculations simpler and less error prone. 
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Annex C (normative): 
Physical presentation 

The DCP (TS 102 821 [2]) allows almost any physical interface to be used. 

All MDl applications shall provide a UDP/IP interface using twisted-pair Ethernet (lOBase-T or better). The parameters 
for the IP stack shall be manually configurable. Automatic configuration using DHCP, BOOTP or similar may also be 
provided. 

Optionally RS232 interfaces may be provided. 

Further optional interfaces may also be included in later revisions. 

A detailed specification of the parameters and hardware of the interface types listed above is provided in 

TS 102 358 [4]. 
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Annex D (normative): 
MDI switching mechanism 



The mechanism described in this annex shall be implemented by any "MDI Switcher" device (a device supporting MDI 
Switching functionality, see below). 

The mechanism may optionally be implemented by DRM Multiplex Generators (which may state the fact of supporting 
this feature). 

One scenario of MDI distribution might be the transmission of several MDI streams in parallel (e.g. via satellite). This 
allows a transmitter site to individually order any DRM Modulator to switch among the available sources of MDI input. 
In this context it might happen that the announcement of a new MDI stream and its configuration is required at the 
transmitter site, while there is no possibility to provide the full stream content in advance of the actual switch time 
(e.g. due to bandwidth limitations or just unavailable content). 



stream A 


Transmitter 
Station 

MDI input 
^ selector 

/ 




<ii|) 


MDI stream B 


;^. 


■ 


stream C 




■ 








^" 




— ► 


DRM 
Modulator 











Figure D.I : MDI Switcher setup - local MDI input selection 

A DRM Multiplex Generator supporting the "MDI switching mechanism" shall create and send out MDI Packets such 
that the time value stored in the "tist" timestamp TAG Item indicates a full minute or a multiple of 400 ms (for 
robustness modes A to D) or 100 ms (for robustness mode E) increments afterwards. The packets whose timestamps 
correspond to the full minute (or multiples of 1,2 seconds (for robustness modes A to D) or 400 ms (for robustness 
mode E) afterwards) shall contain the first frame of a DRM transmission super frame, i.e. the frame number in the 
fac_ item shall be zero and SDC information shall be provided in the "sdc_" TAG Item. This allows easy transition 
between MDI streams originating from different sources. 



D.1 Scenario examples 



Example 1 

A broadcaster provides two MDI streams named A and B via satellite distribution to all its transmitter sites. At a certain 
point in time, all DRM Modulators currently processing MDI stream A shall switch to MDI stream B. 

In this case the broadcaster can provide the correct reconfiguration announcement within MDI stream A in advance for 
all DRM Modulators currently processing MDI stream A. At the point in time indicated by the reconfiguration 
signalling, all DRM Modulators currently processing MDI stream A shall switch to MDI stream B. The transmission 
network capacity occupied by MDI stream A can then be used by a new MDI stream C. 

This transition can be done without any additional external configuration information provided by the broadcaster to the 
transmitter site (except the switch command)! 
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Example 2 



A broadcaster continuously provides two MDI streams named A and B via satellite distribution to all its transmitter 
sites. The DRM Modulators X and Y are currently processing MDI stream A, while DRM Modulator Z processes 
MDI stream B. At a certain point in time, only DRM Modulator Y shall switch from MDI stream A to MDI stream B. 
This can be done fully in accordance with the DRM specification regarding the announcement of configuration changes 
in advance to the DRM receivers: During the reconfiguration period, an MDI Switcher device (which may be 
implemented as a stand-alone device) modifies the MDI stream A on the fly to: 

a) signal the reconfiguration; and 

b) signal the future configuration derived from MDI stream B within the SDC. 

So during the reconfiguration period (of DRM Modulator Y), DRM Modulator X continues to process the unmodified 
MDI stream A, while DRM Modulator Z continues to process the unmodified MDI stream B. Only DRM Modulator Y 
processes a locally modified MDI stream A, containing the announcement for the following reconfiguration to MDI 
stream B. 

This transition can be done without any additional external configuration information provided by the broadcaster to the 
transmitter site (except the switch command)! 

However problems might arise if MDI stream B undergoes a reconfiguration at the same time as the transition from 
MDI stream A to MDI stream B for DRM Modulator Y shall take place. 

Example 3 (MDI configuration announcement) 

A broadcaster provides one MDI stream named A via satellite distribution to all its transmitter sites, along with 
additional non-MDI data. At a certain point in time, some DRM Modulators shall switch from MDI stream A to a newly 
started MDI stream C (replacing some other stream B or alternatively the non-MDI content on the distribution 
network). The broadcaster cannot generally send the required reconfiguration information as part of MDI stream A, 
since some DRM Modulators shall continue broadcasting MDI stream A! 

In this case the broadcaster might choose to start broadcasting MDI stream C some time in advance to the point in time 
when the switch shall take place, to allow the MDI Switcher devices to create the correct reconfiguration signalization 
for the DRM Modulators scheduled to switch from MDI stream A to MDI stream C (see example 1). 
However, if this option is not available (e.g. due to bandwidth limitations on the distribution network), the broadcaster 
may also choose to broadcast MDI Configuration Announcement Packets for MDI stream C. These Packets contain 
no MSC data and are therefore very small in size. 

Note that an MDI Switcher device must not alter the output MDI stream in case of SFN operation, if only parts of the 
SFN are altered or discontinued. Otherwise the receivers within the SFN may receive a fully distorted signal for a few 
seconds (e.g. while some SFN transmitters broadcast the default MDI stream A, while other SFN transmitters broadcast 
an altered MDI stream A including the reconfiguration announcement to another MDI stream B). 



D.2 MDI Configuration Announcement Packets 

To support the MDI switching mechanism by pre-signalling the configuration of an upcoming MDI stream, a special 
version of MDI Packets can be used: "MDI Configuration Announcement Packets". 

The TAG Items contained in an MDI Configuration Announcement Packet must comprise all mandatory and may 
comprise any optional (or proprietary) TAG Item contained in an ordinary MDI Packet (see clause 5), with the 
following exceptions: 

• None of the TAG Items "strO", "strl", "str2" or "str3" must be present. 

This ensures that an MDI Modulator implementation that is not aware of MDI Configuration Announcement 
TAG Packets is not confused by such an MDI Configuration Announcement Packet, because it will simply 
discard it as invalid. 

• The "sdc_" TAG Item, which is normally mandatory only in every third MDI Packet, may be contained in any 
MDI Configuration Announcement TAG Packet, optionally carrying another piece of the total SDC 
information with every repetition. 
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• The "dlfc" TAG Item may be omitted. If present, it should be increased with every MDI Configuration 
Announcement TAG Packet sent and should continue in this sequence during the transition between MDI 
Configuration Announcement TAG Packets and the following regular MDI Packets. 

All DCP parameters used for the MDI Configuration Announcement Packets should be identical to the DCP parameters 
used later for the regular MDI stream. 

The number of MDI Configuration Announcement Packets sent in advance of a new MDI stream shall be enough to 
signal all FAC service parameters of all DRM Services and at least all mandatory SDC information of the new 
configuration. 

MDI Configuration Announcement Packets shall be sent sufficiently in advance to the start of the new (or changed) 
MDI stream, so that all FAC and SDC information is available to the MDI Switcher before the reconfiguration 
countdown is scheduled to start. 



D.3 Timing diagram example 



An example satellite link provides capacity for two parallel MDI streams; 
the total capacity is first used by logical MDI streams A+B, then A+C 
(distinguished by their DCP address): 



MDI Str.A 




Stream A 






MDI Str. B 1 


Stream B 


M 


<unused DCP address> 




MDI Str. C 


<unused DCP address> 


D 


Stream C 



timet 



I %: Stream B ends, Stream C starts 
<t2: regular reconf. announc. B to <off> 
t^: MDI Cfg. Announc. Packet for Stream C 



MDI Switcher device creates individual FAC/SDC multiplex reconfiguration announcements 
per transmitter Tx (^^, if required): 
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Figure D.2 
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